2 . Accessing a Vod System

protect videos and either restrict access or pay royalties, we will not be able to digitize and put material on-line. We believe the best approach to this problem is to encrypt the videos and provide access keys that allow a user to decrypt the video when it is played. The system can manage this mechanism, but it does require hardware support for decryp-tion which most vendors of PC boards for decoding video do not provide. Royalty payment can be based on a charge to watch a video during a specified period (e.g., day, week, semester, or forever) or to use a clip in another document. In the derived work case, a payment plan must be established based on charges for the derived work. We believe this will eventually all be done on-line without human intervention which requires that billing and access control mechanisms be implemented. More work on both the technical and policy issues is required. BDVS provides some reliability support. We use the Tcl-DP Name Server which uses standby spares to reduce the chance that the entire system will fail. If a VFS fails, users with open streams on that server will have to reconnect which may require reloading a video from TS. TS failure is a bigger problem. Our current opinion is that tape-based technology is better than optical disk-based technology because it allows more data to be stored for less money. However, tape is unreliable so you have to keep a backup copy of the video material. This copy is kept on-line presumably on TS which reduces the storage efficiency by a factor of two in space and cost. Tapes fail usually due to wear from being read. The system can track the reads and optimize recopying so that less human intervention is required. It might even decide not to keep backup copies for videos that are deemed less important. More research is needed on this topic. Finally, many people are working on network protocols for delivering video [11]. While real-time protocols like RTP [12] and RTIP [13] will eventually be used everywhere, until then best-effort protocols [14] will still be useful particularly when coupled with reasonably adaptation by client playback software [15].